OPC Studio User's Guide and Reference
Map-through, OPC Nodes and OPC Data
Following attributes are used to create or describe the actual member mappings for OPC Classic (Data Access):
Following attributes are used to create or describe the actual member mappings for data with OPC Unified Architecture (OPC-UA):
In order to describe what precisely happens when these attributes and their combinations are used, it is important do understand that when the mapping is done, there is a “current” OPC node maintained by the mapper object, and a “current” object being mapped. When the mapping is started, the current OPC node is given to the mapper (or, if omitted, starts at the root of the address space), and the current object is the object to be mapped, also passed to the mapper.
As the mapping progresses, the current OPC node is only changed by the DANode (or UANode) attribute. That is, if you want any of your members be mapped to a node different from the parent node, you need to annotate that member with the DANode (or UANode) attribute. The current OPC node is thus changed for that member and anything below it in the mapping hierarchy.
The DAMember and DANode (or the UAMember and UANode) attributes both function as map-through. This means that when they are encountered during mapping, the value of the annotated member is obtained, and the mapping continues into the object given by the value (if the value is a null reference, it is simply ignored). You can therefore have a structure of objects where object’s properties or fields contain other objects, and the whole structure can be mapped at once.
The difference between the DAMember and DANode (or UAMember and UANode) is that with DAMember (UAMember), the current OPC node is not changed. This means that members of the child object will be mapped to the same OPC node as the parent object. With DANode (UANode), however, the members of the child object will be mapped to an OPC node different from the parent. Which node precisely is used for the child object’s members is described in a subsequent chapter, Browse Path and Node Id Resolution. Here, it is enough to say that if you don’t specify any argument to the DANode (UANode) attribute, the current OPC node will be changed to a node with the same name as the member you are annotating. So, if your property is named e.g. Output, it will correspond to an Output node in the OPC address space.
The DAMember and DANode (or UAMember and UANode) attributes do not create any OPC data mappings that can actually have some effect on the underlying OPC system. They are just helper attributes that allow you to define the structure of mappings. In order to create OPC data mappings, you need to annotate your member with either DAItem or DAProperty attribute (in OPC Classic), or with the UAData attribute (in OPC-UA).
With the DAItem attribute, you specify that the annotated member should be mapped to an OPC Data Access item, and you optionally provide additional information about how the mapping should be done. The arguments that you can use with the DAItem attribute allow you to optionally specify:
Note that with the DAItem attribute, you do not specify information about which OPC node (item) should be mapped: This information comes from the usage of DANode attribute(s).
With the DAProperty attribute, you specify that the annotated member should be mapped to an OPC Data Access property (on an item), specify the numerical ID of the property, and optionally additional information about how the mapping should be done.
With the UAData attribute, you specify that the annotated member should be mapped to an OPC-UA attribute, and you optionally provide additional information about how the mapping should be done. The arguments that you can use with the UAData attribute allow you to optionally specify:
Note that with the UAData attribute, you do not specify information about which OPC-UA node should be mapped: This information comes from the usage of UANode attribute(s).
Typically, when the structure of your objects follows the structure of the OPC address space, you will annotate object members as follows:
It is, however, perfectly possibly (and indeed, practical) that your objects may have a structure that differs from a structure of the OPC address space – either just at some places, or globally. In such case, you can still make your objects “fit” the address space, by proper placing of all attributes described here.